テスト駆動開発 Kent Beck
テスト駆動開発 Kent Beck
動作するきれいなコード
TDDとは
プログラミング中の設計判断とフィードバックの間にあるギャップを認識すること
そのギャップをコントロールする技法
よくわからんmiyamonz.icon
三部構成
多国通貨
多国通貨計算の例題
xUnit
実際のテストフレームワークを開発しながら学ぶ
これかなり面白いことやってるmiyamonz.icon
テスト駆動開発のパターン
どのようなテストを書くかの判断に関するパターン
シンプルなルール
コードを書く前に、失敗する自動テストコードを必ず書く
重複を除去する
TODOリストを書いて、それを行うテストを書く
コンパイルエラーもテスト失敗としてみなす
重複を除去する
TDDのサイクル
テストを書く
ほしいインターフェースを創作する
動かす
正しくする
仮実装と明白な実装
仮実装
ベタ書きで無理やりテストを通して、徐々に変数に置き換える
明白な実装
すぐに頭の中の実装をコードを落とす
どっちもOK
明白な実装で進めて、ちょっとでも予期しないレッドバーをみたら、仮実装にシフトすると良い
自身が戻ったら明白な実装に戻る
必要に合わせて揺れ動くと良い
三角測量
コードが一般化できるのは、２つ以上の実例があるときだけ、とする方法
仮実装で通して、
テストのアサートを増やす
その後に一般化してく
筆者によると、どうやってリファクタリングしたらよいか全くわからないときにしか使わない
どうやって一般化するかわかってるなら、そのとおりやるから
正しいコードが書けるときに、それでもその他のテストを追加しなければいけないのは変
しかし、設計のアイデアが浮かばないときは、三角測量は使える
作成したばかりの機能で、テストを改善する
ただし、正しく検証できてないテストが２つあると難しい
そのリスクを受け入れる
テスト対象オブジェクトの新しい機能で、テストコードとプロダクトコードの間の結合度を下げる
3年前に読もうとしてよくわからず放置してたが、やっとすごさがわかってきたぞmiyamonz.icon
アクロバティックなリファクタリングをするためのガードレールとしてのテスト
テストするとは
評価する、という動詞
テストは独立であるべき
１つ失敗したら、問題は１つ
todoリスト
テストする前に必要になりそうなことを書く
テストファースト
アサートファースト
システム構築はどこから始めるか
システム構築が終わったらこうなる、というストーリーを語る所から
機能はどこから書き始めるべきだろうか
コードが書き終わったらこのように動く、というテストを書くところから
テストはどこから書き始めるべきだろうか
テストの終わりにパスすべきアサーションを書くところから
テストは下から書くかたちになる
問題を切り離そう
正しい結果とはなにか
それをどう検証するか
テストデータ
読みやすく、理解しやすくなるデータを使おう
ホンモノに近いデータ
明示的なデータ
一歩を示すテスト
はじめのテスト
何もしないことのテストから始める
すぐに掛けそうで
そこから学ぶものがありそうなものにする
説明的なテスト
学習用テスト
動作確認としてテストを書く
依存パッケージの新しいバージョンがリリースされたら、まず学習用テストを走らせる
これが失敗するなら、自分らのコードも動くはずがない
脱線はtodoリストへ
回帰テスト
モックオブジェクト
本物があるなら、同じテストを本物にも走らせる
self shunt
テストケース自体をモックオブジェクトにする
log string
ログを文字列とかsetに格納する
crash test dummy
仮実装
テストを失敗させたままにする
途中で止めるときに良い
きれいなチェックイン
チームでは、結合テストスイートで失敗するかも
最もかんたんなのは、手元の作業を捨ててはじめからやりなおす
不具合修正してチェックインする猶予を与える
でも、これもちょっと試してだめなら捨てるべき
仮実装
動かないものよりも動いてることに価値があるから
書いてみたら、テストが正しく書かれていないことに気づいたりもする
三角測量
１から多へ
オブジェクトのコレクションは、単数のときの操作を実装し、それからコレクションでも動くようにする
配列の合計などは、まず１つだけ渡したときの動作をテストする